Size Change: -838 B (0%)

Total Size: 1.37 MB

_{compressed-size-action}

@sarayourfriend I think this is a great approach! The "breakdown" of the individual deprecated props provides a replicable strategy for handling remapping/deprecation/(removal?) of props :).

I think Button is honestly the most challenging component due to how common it is within the UI (both from core and 3rd party).

Running Gutenberg locally, we can see the UI breaking in many areas 🙈 .

It's mostly style based. However, I think this reveals a lot of awkward / sub-optimal uses of Button.

A downside of this strategy is that we can't incrementally scope and roll-out the new implementation - via the protection of the Context System.

I think it's worth noting that there's a difference between rendering a UI with button HTML, and using the actual Button component. In the case of the Inserter tiles (screenshot above), I don't think they should be using the Button component as a base.

Thanks for the screenshot @ItsJonQ. That really illustrates one of the significant difficulties of this migration process. Like you said, the approach taken in this PR doesn't allow for piecemeal, area-by-area adaption. The new component must work for all instances. I think that's a fine expectation if we take this approach, but obviously more work needs to be done on ui/button before it's actually feasible.

I upgraded G2 and it fixes some of the problems but not all. Upgrading G2 gets us the new low specificity.

I'll note that I think that "an API without compromises" doesn't exist, what we might think is perfect today, might not be tomorrow, for this reason, sometimes, it's fine to avoid introducing a new API even if admittedly it's better than the existing one but if it's merely a proxy or renaming of existing prop, I might ask why bother at all. This is me saying that aside "this is a better name for the prop or a better format" we might want to think about whether the tradeoff to rename or change the format of a prop is worth the deprecation or if it's it fine just to keep the old API.

I echo what @youknowriad mentioned. I see that public APIs between the old and new version of the button differs a lot. I would personally look at this from a plugin developer perspective that might suddenly see a big number of warnings coming from components they use in the project. There isn't any immediate benefit for them to start using the latest API because the button will work more or less the same. It's important to be aware of that side of the components adoption and ensure that it doesn't become too troublesome and folks will lose confidence in using WordPress components.

A couple questions for @ItsJonQ regarding this PR.

I think this PR exposes something about G2's Button that was not talked about yet. Basically, it is too different from the existing Button. Aside from API improvements, are there aspects of the G2 Button that are "must haves" that the current Button does not implement?

My thought behind asking this question is: can we actually just use the existing button, improve it in some ways (including by refining the API to use a variant prop instead of the various is* props)? Button in particular seems like a bit of a quagmire in that it is used all over the place. I don't think we'll be able to achieve a reasonable integration strategy that includes Button because of this. A more straightforward option would be to just improve the existing Button, potentially rolling the existing button into the G2 style system so that it can be targeted using Component Interpolation in styled components to make way for ButtonGroup's automagic handling of rounded corners and such (one thing the new Button does well that we should backport into the existing one if we just keep the existing one).

Are there also other components we can do this with?

I'm going to open two new PRs that are inspired by this one. One for Text and one for Flex. I think these components in general can actually use this current strategy and get to a mergable place soon.